OK, shoot some holes in this technique.....
DOORS 9.2+
I have a module that needs some of the objects frozen to read only while others and new objects remain R/W for a specific group. After some experimenting with shared edit, inheritance, etc. I think I may have come up with a way to do this.
Known: The module is currently 1500 objects, will probably grow to 2000, but not much more than that. I have removed inheritance on every object (1500 shares), and the initial save takes about 20 seconds. After that, individual edits aren't too bad.
most of my leaf objects are at level 4. For ones higher, we can use Exclusive Edit when needed.
How I set up the module:
1. Determine the highest access capability and make that group - Rqt Editor = RMCD
2. Make sure that all objects are inheriting - Run script to set all objects to inherit
3. run a script to set Rqt Editor permission to read, based on the value of an attribute (for me, Effectivity)
4. go back into the module, and set up sharing, selecting level 4.
Result: any object with a build effectivity of 1 is set to Read for the group Rqt Editor, regardless of edit mode, yet I have a level 4 share setup, allowing editing of non build 1 objects. I have 140 sharable sections instead of 1500. This looks like what I want. What am I potentially messing up, or not thinking about?
TIA
cliff.sadler - Mon Mar 28 15:56:18 EDT 2011 |
Re: Controlling Access on individual objects in a module
llandale - Mon Mar 28 17:21:02 EDT 2011
I get confused and like to restate things to make sure I understand. I think you are saying you want a reasonable number of shared sections in the module and allow general Edit, but want to protect Effectivity=1 objects from the general population. To do that you provide general Edit to the module, define level 1/2/3/4 objects as shared sections, and deny general edit to Effectity=1 objects.
Good plan; with these tweaks:
o Better to restrict level 1/2/3/4 HEADINGS to be specific Sections.
o Before providing access to the Effectivity=1 object you need to set it to "specific(o)".
o Your script should manage the shared sections completely. <1> First erase all shared sections (inherited(o)). <2> Then find all the 1/2/3/4 level headings and set them Specific. <3> Then find all the Effectivity=1 objects and set them specific and deny write acccess. bla bla snip snip.
I see a problem when your Effectivity=1 objects have children objects that are not also Effectivity=1. If you set them to 'Specific' you'll need to provide that group RMCD access, otherwise it will 'inherit' access from the parent which denies that access. Lets hope ALL your Effectivit=1 objects are leaves.
It gets real sticky. Perhaps a pre-save-attr trigger that denies the change for Effectivity=1 objects unless the user is indeed in a specific privaleged group or possesses RMCDA access to the module.
|
Re: Controlling Access on individual objects in a module
cliff.sadler - Tue Mar 29 14:45:44 EDT 2011 llandale - Mon Mar 28 17:21:02 EDT 2011
I get confused and like to restate things to make sure I understand. I think you are saying you want a reasonable number of shared sections in the module and allow general Edit, but want to protect Effectivity=1 objects from the general population. To do that you provide general Edit to the module, define level 1/2/3/4 objects as shared sections, and deny general edit to Effectity=1 objects.
Good plan; with these tweaks:
o Better to restrict level 1/2/3/4 HEADINGS to be specific Sections.
o Before providing access to the Effectivity=1 object you need to set it to "specific(o)".
o Your script should manage the shared sections completely. <1> First erase all shared sections (inherited(o)). <2> Then find all the 1/2/3/4 level headings and set them Specific. <3> Then find all the Effectivity=1 objects and set them specific and deny write acccess. bla bla snip snip.
I see a problem when your Effectivity=1 objects have children objects that are not also Effectivity=1. If you set them to 'Specific' you'll need to provide that group RMCD access, otherwise it will 'inherit' access from the parent which denies that access. Lets hope ALL your Effectivit=1 objects are leaves.
It gets real sticky. Perhaps a pre-save-attr trigger that denies the change for Effectivity=1 objects unless the user is indeed in a specific privaleged group or possesses RMCDA access to the module.
I do not allow, and I check for and clean up chilren of leaves. I appreciate the comments.
|